Tile based rendering is a known technique for rendering 2D or 3D computer graphics images. A rendering space is sub-divided into a plurality of regions called tiles or blocks, which are typically rectangular, and each comprises a plurality of pixels. The rendering space may correspond to an image for display on a screen, but other render targets, such as texture data in memory, are also possible. Tiles can be various sizes, but a typical size is for example 16×16 pixels. In a high screen resolution image there are typically 1280×1024 pixels. Therefore, a high screen resolution image may be sub-divided into 5120 tiles (each comprising 16×16 pixels).
Primitive data representing geometrical objects is read from memory and transformed into screen space. Primitives are often polygons, typically triangles, but may be lines or points. A display list is then derived, for each tile, indicating the primitives, if any, which are located either partially or wholly within the tile. The display lists may include identifiers for each of the primitives which reference or provide a pointer to geometrical data associated with the primitive stored in a parameter memory. Where a primitive is located over more than one tile, this avoids having to store geometrical data for that primitive multiple times. However, it will be appreciated that, particularly as computer graphics images have become more complex, a large amount of data must still be stored in the display lists for the tiles in order to indicate all of the primitives located within each tile. A large amount of data must also be stored in the parameter memory.
After the display lists have been created, each tile is rendered independently using its display list.
It is known to perform hidden surface removal, such that further texture and shading is only applied to visible surfaces.
Hidden surface removal typically uses a technique known as “z-buffering”. For each tile, the geometrical data for each of the primitives identified in the display list is read, and depth values are calculated for each primitive at every pixel in the tile covered by the primitive. Processing each primitive in turn, these depth values are compared to the respective depth values stored for each of the pixels in a “z buffer”. If it is determined that a new primitive is closer to the viewpoint or eye at one or more pixels than the previously processed primitives, then the pixel values, including the depth value, stored for each of those pixels is replaced with the values of the new primitive at the respective pixel. If it is determined that a new primitive is hidden or obscured behind other primitives in the image at one or more pixels, then the pixel values, including the depth value, for each of those pixels is not changed. Once all of the primitives have been processed, the resultant pixel data for visible primitives is passed to a shading unit which applies textures and shading to each visible pixel within a primitive. After final pixel values have been determined for each pixel in the tile, the pixel data for the tile is written to memory for display on an output device.
Methods for culling primitives which are entirely hidden (that is primitives which are not visible at any pixels in the tile) without having to perform all of the processing required by the “z-buffering” hidden surface removal technique for all visible pixels from the primitive are known. For example, GB patent No. GB 2,378,108 discloses a technique where depth values of the primitives are first compared with the range of per pixel depth values from previously processed primitives stored in the “z buffer”.
By way of example, FIGS. 1 and 2 show the depth range of per pixel depth values from previously processed primitives and a new primitive indicated by reference numerals 10 and 20 respectively. In this illustrative example, only the x and z directions are considered, for clarity. In these diagrams, the furthest point from the viewpoint is assigned the depth value 1.0, and the closest point the depth value 0. The depth values of each pixel in the tile stored in the “z buffer” are indicated by a solid line. The depth range of the previously processed primitives (that is, the greatest or maximum depth from and the closest or minimum depth to the viewpoint) is illustrated by two dotted lines. In this example, in FIG. 1, new primitive 10 is closer to the viewpoint than the maximum depth of the z range. This primitive is therefore not culled and is processed using the “z-buffering” technique described above. FIG. 2 shows how the depth values stored for each of the pixels in the tile are updated. Since in this example primitive 10 is visible at all of the pixels at which it is located, the depth values for each of the pixels covered by primitive 10 are replaced with the depth value of primitive 10 at the respective pixel. If primitive 10 were only visible at one or more pixels, then only the depth values for those pixels would be replaced with the depth value of primitive 10 at the respective pixel. It will be noted that, in this example, this means that the z range has changed, and in particular the maximum depth of the z range is now closer to the viewpoint. New primitive 20 is now processed and, as illustrated in FIG. 2, the minimum depth of new primitive 20 is greater than the maximum depth of the updated depth range. Thus, new primitive 20 is entirely hidden by other primitives in the tile and can therefore be culled without processing the primitive further.
This method has the advantage that primitives which are known to be entirely hidden by other primitives located within the tile can be culled without having to perform all of the processing required by the “z-buffering” technique for each visible pixel from the primitives. However, those primitives are still indicated in the display lists for the tiles. This means that memory space is used unnecessarily storing an indication of those primitives in the display lists for the tiles. In addition, geometrical data associated with those primitives may be unnecessarily stored in the parameter memory. Memory bandwidth is also therefore wasted reading data for those primitives from the display list/parameter memory in order to process those primitives.
GB patent GB 2,378,108 proposes that hidden primitives may be culled before they are indicated in the display lists for the tiles, if a technique called “partial rendering” is used. In this technique, only a portion of the primitives located within a tile are indicated in the display list for that tile, and then those primitives are rendered as described above using the z buffering technique. The z range of the depth values stored in the “z buffer” after the “partial render” is fed back to the unit performing the tiling. The tiling unit then compares the depths of the next primitives to be indicated in the display list for that tile with this z range information as described above and culls any primitives which are determined to be entirely hidden by other primitives in the tile.
This method enables some primitives which will be hidden in the image to be culled before they are indicated in the display lists for the tiles. However, “partial rendering” is a fall-back method used by a tile based computer graphics system when it runs out of parameter memory before finishing processing all the primitives in a render (for example the system has to render part of the display list to free parameter memory, thereby enabling new primitives to be added to the display list). Partial rendering is slow and expensive for hardware and is avoided if possible. Furthermore, it will be appreciated that this method is not as accurate as performing the depth test after the display lists have been derived, during rendering of the tiles, since the z range information with which the depths of the primitives are compared is not as up-to-date. The z range is only updated after each partial render. This method cannot be used with tile based systems which do not use “partial rendering” or a system where at least some primitives located within a tile are rendered before all of the primitives located within the tile are indicated in the display list for that tile.